Player Contracts: A Design Document

 

http://forums.station.sony.com/swg/board/message?board.id=csystems&message.id=4421

 

2004/01/26

 

INTRODUCTION

 

In writing an essay on the Economic Stages of MMOGs, I came up with the notion that online games would benefit from providing more ways for players to interact economically. This idea of "player contracts" seemed like a particularly worthwhile idea to explore, so I've developed that idea further here.

 

Please note that this is a fairly lengthy document. That's not because the concepts are particularly complex, but more because I wanted to give the details a good airing to try to address the most likely objections. If you're able to take the time to read this proposal and give the whole thing fair consideration, I appreciate your effort. Thanks!

 

WHAT ARE "SECURE CONTRACTS"?

 

A secure contract is an agreement between players to exchange items of value that is enforced by the game system. This document will describe a design proposal for implementing this concept within Massively Multiplayer Online Games (MMOGs) and detail the reasoning supporting the proposed implementation.

 

WHY SECURE CONTRACTS?

 

I go into the "why" in greater depth in the Economic Stages of MMOGs essay, but in a nutshell: virtually all MMOGs are stuck in an economic Stone Age because they don't offer the necessary in-game systems to support more advanced economic action. Goods and money can be traded in one-shot deals, but that's no better than Og the Caveman could accomplish. A more advanced economic system in MMOGs is desirable because it would deepen the playing experience, not just in the obvious form of allowing more competitive and cooperative player interactions, but also by expanding the range of economic opportunities available to all players (in the same way that advanced economic systems in the Real World offer economic opportunities to individuals that would otherwise be unavailable). Therefore, identifying and implementing more advanced forms of economic activity in MMOGs is desirable.

 

Several key in-game systems need to be designed and implemented to permit an advanced online economy. One of these is a system of cheat-resistant player-to-player trade contracts. Early MMOGs allowed players to exchange goods and money, but these proved to be susceptible to several forms of cheating. The fear of being cheated thus limited economic activity. To counter the most common cheats, the Secure Trade concept was devised. By encoding trading rules that prevent the twin scams of item misidentification and item substitution, a Secure Trade allows players to trust each other when considering whether to exchange goods and money. This increased trust encourages more economic activity than would otherwise have taken place, which is the goal this proposal aims to deliver, so it's worth examining the Secure Trade concept in more detail to see how this is accomplished.

 

As noted, Secure Trades promote trust by protecting players from the two most common trading scams. First, a Secure Trade Window shows item names and item descriptions separately, using a game rule that allows players to set item names but retains system-generated item description text. Displaying system-defined item descriptions tells each player exactly what is being offered, preventing unscrupulous players from selling items with "fake" names. (For example, the description of an item can't read "+10 Healing Juice" and just be a bottle of water. If it's just water, the description of the item will say so no matter how the item is named.) Second, a Secure Trade prevents the terms of a deal from being modified after one person has agreed to the deal. As soon as one player accepts the deal as offered, the only options are to accept or cancel the deal in its entirety. This restriction prevents a player from replacing a good item with a piece of junk after the other player has agreed to the original deal.

 

These two features of Secure Trades allow players to trust other players in exchanges because they know they'll get what they think they're getting. It's still possible to make bad deals on the value of the goods exchanged, but at least players can trust that the system itself won't be used to cheat them.

 

But it's also true that Secure Trades are limited in two important ways. First, they only let players trade goods and money. That's fine as far as it goes, but what if I as a player want to offer a service to another player within the game? How can we trust each other to keep the terms of an informal agreement when there's no system-controlled enforcement of those terms? Second, Secure Trades are one-shot, immediate deals. They don't allow a player to establish an ongoing business relationship with another player by creating deals that happen in the future, or that happen more than once. Again, such agreements can be and are made informally in active MMOGs, but not as many as might be made if players had access to a game-controlled mechanism for enforcing the terms of trade agreements.

 

Still, the Secure Trade system, while limited, does work. That makes it a good base on which to attempt to build a more advanced trade system in which a single exchange of goods and money is just one type of player-to-player contract within a general contract system. Secure Trades increased economic activity by establishing trustability in simple exchanges; Secure Contracts can increase economic activity yet again by expanding the number and types of trustable interactions that can occur. The rest of this document will discuss specific elements of a Secure Contracts system for use in MMOGs.

 

SECURE CONTRACTS OVERVIEW

 

This design defines a Secure Contract to be a general trade agreement between two players whose terms are enforced by the game. Player A (the "contracting player") agrees to provide goods or money to Player B in exchange for Player B (the "contracted player") agreeing to provide goods, money, or a specific service to Player A. (Exchanges of money for money would not be allowed, of course, unless a MMOG offers several different currencies and wants to allow arbitrage.)

 

Two modes of secure contract are possible in this system: the Personal Secure Contract, negotiated iteratively in real time between two players whose characters are within a certain minimum "physical" range of each other, and the Open Secure Contract, specified by a contracting player but publicly available for acceptance by any player.

 

Before the mode of a "live" contract is set (determined by how the contracted party receives the contract offer), it might be useful to generate "draft" contracts.

 

THE DRAFT SECURE CONTRACT

 

Any player would be able to generate a draft Secure Contract. A click of the appropriate button would cause the Secure Contract Window to be displayed on the player's screen. She would first select the desired contract type from a drop-down list. Once a contract type is chosen, the terms specific to that contract would be displayed and the possible options within each contract term would be selectable. When the values of the initial contract terms are set to the player's satisfaction, she could set the contract aside in her inventory for later use. If she subsequently offers the draft contract to a nearby active player who agrees to the terms, the "live" contract is created at that time as a Personal Secure Contract. If instead she offers the draft contract to some form of game-controlled public system for retaining and displaying potential contracts, then once another player agrees to such a contract it becomes an Open Secure Contract. If a player who is offered a draft contract rejects it, or if the player who created a draft contract retrieves it unaccepted from a public contract display system, then this contract returns as a draft Secure Contract to the inventory of the player who created it.

 

Note that for technical reasons it might be undesirable to allow players to generate and retain draft contracts. In this case the mode of contract a player generates (Open or Personal) would be determined by the means of generation. A Personal Secure Contract would be generated by offering a contract to another player, with all contract terms negotiated in the Secure Contract Window at that time. An Open Secure Contract would be generated by offering a contract to a "contract terminal" or "lawyer" or some other game-controlled public contract provider appropriate to the game milieu. The player offering the contract would be able to set all applicable contract terms in the Secure Contract Window until the contract is offered to the public contract provider.

 

In either case, if the player making the contract offer will be providing actual money or goods as payment, then the full value of the payment (for each time the contract is activated) must be transferred from the contracting player�s personal inventory, bank vault, or bank account into the contract�s "payoff account" container. This requirement will insure that the contracting player is actually able to make the deal being offered, which will help reduce the number of frivolous contract offers.

 

PERSONAL SECURE CONTRACTS

 

The contracting player of a Personal Secure Contract would begin a negotiation by offering a contract to another nearby player. If the other player accepts the offer to negotiate a contract, the Secure Contract Window is displayed on both players� screens. The Secure Contract Window would initially offer a choice of contract type. When a particular contract type is selected, the contract terms specific to that type of contract are displayed, possibly with some default settings selected. The contracting player would set the initial terms, then the contracted player would then have an opportunity to alter the terms of the contract. The contracting player would then be able to alter the terms again, and so on. This process of iterative negotiation would be allowed to continue until one player cancels the contract offer or both players explicitly agree to all the terms. Note that, as with the Secure Trade Window, once either player has indicated agreement to the terms displayed in a Secure Contract Window, the other player may not alter any of the terms -- the only options available at this point are to accept the contract as-is, retract the conditional agreement, or cancel the contract offer entirely.

 

Among the terms that both players may negotiate are the specification of what will be exchanged and in what quantities, when exchanges will occur, whether either party can cancel the contract without penalty, and (optionally) any penalties for canceling a contract or otherwise failing to meet the terms of the contract. As noted above, the contracting player would initially be required to transfer to the contract the full amount of goods or money being offered for exchange. If the deal is a simple swap of money for goods, the contracted player would then enter at least one unit of some good currently held in his personal inventory into the contract's "provision account," then specify the number of units of this good to transfer each time the contract is activated. (Requiring at least one unit of a good to be put into any contract account is necessary to avoid forcing players to choose from a gargantuan list of all possible goods. Not only would this be a complex data structure to store and display, it might reveal some resource details a little too conveniently.) Optionally, both players could also enter some amount of money into a "penalty account" if there is to be a penalty for failure by either party to adhere to the terms of the contract.

 

OPEN SECURE CONTRACTS

 

Although the contract system was originally envisioned as allowing two players to negotiate contracts together in real time, the system could be extended to allow what I call Open Secure Contracts, that is, contracts created by one person and placed in some public location (probably a "contract terminal" in SWG). Other players could browse the list of contract titles from the public contract provider, then examine the details of a specific contract whose title sounds interesting. Note that to prevent two players from taking the same contract, as long as a contract�s title is visible to one player it should not be displayed by any other contract provider list. If the player reading the open contract likes all the terms as stated by the offering player, he would agree to them and the contract would go into effect between those two players (with appropriate contract documents provided to both players). If the proposed contract isn't acceptable, the player reviewing the details simply cancels and the contract is restored to public availability. In essence, an Open Secure Contract is simply a publicly available contract to which the contracting player has already agreed.

The downside of this approach is that the contracted player wouldn't be able to alter the terms of the contract; his only choices would be to accept all the terms exactly as laid down by the contracting player, or else to reject that contract entirely. But the standard two-way negotiable Personal Secure Contract would still be available to players who prefer to haggle over terms. Allowing open contracts would merely expand the scope of contract availability.

 

[Note to SWG players: Actually, I'm a little embarrassed to say this but it seems to me that there's another name for an open contract system: "player missions." It's not what I meant to design, but it sure looks like functionality that would support player missions. Oops.]

 

ACTIVATING A SECURE CONTRACT

 

As soon as both parties agree to a contract, it takes effect. If both players have at least one available slot in the appropriate part of their personal inventory, and if the specific type of contract that was agreed to was not of the "immediate" variety (defined below), then both players receive a contract document as an inventory item. (In SWG, this would take the form of a data file in the datapad.) This document lists the terms of the contract in a read-only form.

 

Once the terms of the contract are met and the contract is "activated," the goods or money in the contract's payoff account are transferred to the contracted player, while the specified amount of any goods or money named in the provision account are transferred from the contracted player�s inventory or bank account to the contracting player's inventory or bank account. In the case of an immediate contract (see below for the definition of an "immediate" contract), this transfer occurs as soon as both parties agree to the contract. Any goods offered by the contracting player are transferred from the contract�s payoff account to the personal inventory of the contracted player, while any goods offered by the contracted player -- in the amount specified by the contract -- are transferred directly from the contracted player�s personal inventory to the personal inventory of the contracting player. (This approximates the current behavior of Secure Trades to remain consistent with existing functionality.) Similarly, money is deducted from the payoff account to the contracted player�s bank account, or directly from the contracted player�s bank account (in the amount specified by the provision account) into the contracting player�s bank account.

 

More complex contracts would allow for multiple exchanges of goods and money (or services) at specified intervals, and for exchanges that take place at some time in the future from when the contract is agreed to. Money transfers would automatically deduct the amount of money specified in the contract from the offering player's bank account and add it to the other player's bank account. Similarly, if goods are being exchanged the allotted number of specified goods would be taken from the offering player's bank vault and placed in the other player's bank vault. Note that non-immediate exchanges (that is, exchanges set to occur some time after the contract is signed) use player bank vaults rather than personal inventories to minimize problems caused by personal inventories being temporarily full at the moment a future contract is activated. However, a contracting player would still be required to put the full amount of goods or money into the payoff account for the first exchange � again, this is to give players who are offered contracts the reassurance that the offering player can actually deliver on his promised payoff.

 

One possible modification of this system would be to require that the contract system automatically replenish the contents of the contracting player�s payoff account each time the contract is activated (rather than taking goods or money from the contracting player�s bank vault or bank account after the first exchange). This would appear to automatically deduct goods or money from the contracting player, and so might not be desirable. (Automatically crediting goods or money is fine, but automatically deducting goods or money could lead to player complaints if it causes too many contracts to fail due to insufficient goods or funds.) It would, however, provide further assurance to a contracting player that the contracting player is always able to fulfill the agreed terms of a deal each time it is activated.

 

In all cases, if at any moment of contract activation either player doesn't have enough of the agreed-upon goods or money, or doesn't have enough room to receive the provided goods, or in any way cannot provide or receive the goods or money or service required by the terms of the contract, then that player will have broken the terms of the deal. At this time any items in the payoff and provision accounts are returned to their original owners (if possible), any money in the penalty account is transferred to the bank account of the player who did not fail to be able to give or receive money or goods (or is split between the players if both failed to be able to give or receive the agreed-upon goods or money), the contract documents are deleted from both players' inventories and the contract terminates. Additionally, deleting the contract document will constitute canceling the contract, and may under certain circumstances (see "bilateral contracts" below) cause any penalty money to be transferred to the player who did not cancel the contract.

Now that the basics of the Secure Contract system have been described, let's examine the specific features of this system.

 

SECURE CONTRACTS FEATURES

 

A system to allow Secure Contracts should implement the following features:

 

 

1. VARIETY OF EXCHANGE TYPES

 

Numerous specific and distinct contract types should be available. (In SWG, these would mirror the types of NPC missions the game already offers, with perhaps a few additions, omissions, and modifications.) Examples of possible contract types are:

 

Exchange

swap goods for goods or goods for money

Tribute

give another player goods or money for an unspecified reason

Transport

move items [or player characters] to a specified location

Delivery

give items to a specified player character or NPC

Recon

go to a particular location

Obtain

take possession of a specified item

Entertain

perform within 20 meters of a specified player character or NPC

Heal

heal or cure a specified player character

Buff

improve the stats of a specified player character

Craft

create a particular kind of object, possibly with certain stats

Slice

hack a container (to open it) or an item (to improve its stats)

Destroy

eliminate a specific lair, destroy a unique item, or kill a creature mob

Guard

defend a specified player character or NPC for a specified time period

Bounty

kill a specified player character or NPC [who must agree to be a target]

Marriage

marry another player character [allows for divorce, too]

 

(This is not a definitive list!)

 

Each of these contract types would have optional terms, some of which might be common to most or all types, and some of which would be specific to that contract type. The Exchange contract, for example, is our old friend the Secure Trade, but with additional options for when and how often to make such trades. (Time options are discussed in the next section.) The Recon contract would simply offer a reward for scouting out a given location. (This sounds easy... but in SWG, what about sending an overt player to spy on some location deep within a city of the opposing faction? Not so easy!) The Delivery contract would let you pay someone to give a droid containing the plans for a terrible new Imperial weapon to a hermit living somewhere in the desert on Tattooine... you get the idea.

 

2. VARIETY OF EXCHANGE TIMES

 

Player exchanges should be allowed to occur in any of the following five ways:

 

 

Another way to look at this is to say that contracts should be specifiable in terms of lifespan and frequency. Lifespan options are:

 

 

and frequency options are:

 

 

So Contract A might be set up as an immediate+one-time deal -- you and the other player swap goods or services or money once, and that's it. (This is the standard Secure Trade.) Contract B could be a limited+one-time trade, in which both players identify types and amounts of goods or money to be exchanged, but the actual exchange does not occur until the selected time. (This could be useful for selling resources you haven't gathered yet.) Contract C might be made as a limited+recurring deal -- for example, you and the other player swap the agreed-upon goods and money every 24 game hours until five game days have passed, at which time the deal automatically expires. Contract D might be made as an indefinite+recurring deal -- you and the other player exchange the agreed-upon goods/services/money every 12 game hours until the end of time... or until one of you defaults on the contract or manually terminates it.

 

3. PLAYER-SPECIFIED CONTRACT TERMINATION

 

Contracts should have two mutually exclusive termination options:

 

 

Unilateral simply means "one-sided" -- one player may choose to end the contract without the other player's agreement, and this won't cause the penalty (if any) to be applied. A bilateral contract, on the other hand, would require agreement by both players to terminate a contract without penalty. If Player A and Player B agree to a bilateral contract and Player B terminates the contract without Player A's consent, then any penalty would be applied against Player B as described in the next section.

 

4. VARIETY OF PENALTIES

 

There are two types of penalties that could be applied if one player breaks the terms of a contract:

 

 

A monetary penalty is a lump sum of cash given to the player who didn't break the contract. When agreeing to the contract, both players agree to a total amount of cash to be placed in a "penalty account." Half of this amount is deducted from the bank accounts of both players as soon as the contract goes into effect to insure that the penalty can be paid if necessary. (If either player has insufficient funds to cover the amount agreed to, both players get an error message to that effect and the contract is not agreed to.) Once the contract goes into effect, if one player breaks the terms of the contract, all the money in the penalty account is transferred to the other player's bank account and the contract terminates.

 

Another optional penalty would be to subject the person who prematurely breaks a bilateral contract to a Bounty contract that can be taken by a Bounty Hunter. Both contractees would agree on a bounty amount, half of which would be transferred from each player's bank account into the penalty account when the bilateral contract is agreed to. As soon as one player breaks the contract, the original contract is terminated; a Bounty contract (much like existing Bounty Hunter missions in SWG) is created and becomes publicly available with the money in the penalty account set as the reward; and the player who broke the original contract receives a "Bounty Flag" (like a TEF, but handled separately from a TEF). The first bounty hunter who kills the flagged player character immediately has his bank account credited with the bounty from the penalty account; the contract-breaking player's clone has the BF lifted (so that he's not a perma-target); and the bounty contract terminates. (Note that other forms of dying, such as being killed by a monster or NPC, do not remove the Bounty Flag!)

 

It would be entirely up to the two players making the deal to decide whether they want to apply a penalty at all. In other words, penalties would be optional -- if neither player wants one, then they shouldn't be forced to have one.

 

5. AUTOMATIC TERM RESOLUTION

 

The contract system must be designed so that the game itself recognizes when the terms of a contract have been fulfilled or breached. Leaving it up to players to decide when the terms of a contract have been met would open the contract system to subjectivity, which would effectively doom a contract system. If some MMOG wanted to implement a game feature in which players could be lawyers and judges, and thus offer some means by which to litigate contract disputes, fine; otherwise the game system itself should be established as the ultimate impartial arbiter of contract resolution.

 

This ability to detect the satisfaction of contract-related conditions is the beating heart of the Secure Contracts system. The game absolutely must be able to reliably detect when the terms of contracts have been met or breached. The technical issues involved should be investigated to insure that this is possible. As a starting point I believe such a condition-monitoring system could be implemented as part of a "contract engine"; that is, as a cluster of tightly-integrated code modules which would perform the following tasks:

 

 

There are two possible states for a condition: "false" (when a contract is created), and "true" (when something in the game has happened that is part of the terms of the contract). In addition, conditions themselves are classified as either "positive" or "negative."

Contracts themselves can have four possible states: "open" (when a contract is waiting for conditions to be fulfilled), "activated" (when all positive conditions in a contract become true), "failed" (when any negative condition becomes true), and "complete" (when all positive conditions in a one-time contract become true, or any negative condition becomes true, or a unilateral contract is cancelled).

 

To be clear about how contract statuses change: if when a contract's conditions are scanned all positive conditions are true, set the contract's status to "activated"; if any negative conditions are true, set the contract's status to "failed." The "activated" status corresponds to successful fulfillment of a contract's terms, while a "failed" status indicates that something has happened to make fulfilling the contract impossible (that is, the terms of the contract have been broken). Certain other conditions (canceling a unilateral contract) will simply set a contract's status to "complete" without forcing either a successful exchange or a penalty application.

 

To see how this would work, let's consider an example. Suppose a player accepts an indefinite+one-time contract to destroy a creature lair. A Destroy contract (let's say it's also a bilateral contract) is created and maintained in a list of contracts. If the contracted player destroys the specified lair, the game system must recognize this event and update the value of the positive "contracted player has destroyed lair" condition for that particular Destroy contract to "true". Since this is the only positive condition, the contract's status is set to "activated"; the terms for successfully performing the contracted task are activated (that is, the contents of the provision and payoff accounts are swapped); the entire contract's status is changed from "activated" to "complete," and at the proper time the completed contract is deleted from the contract list (and the contract documents in the inventories of both players are deleted as well).

 

If (using the same example) the lair despawns or ceases to exist for any reason other than because the contracted player destroyed it, then this fact must be signaled to the appropriate condition in the Destroy contract in the contract list -- specifically, the value of the negative "player cannot destroy lair" condition would be set to "true." When this contract's conditions are scanned, the contract's status would be updated to "failed"; when contract statuses are checked any penalty terms specified by that contract would be imposed on the appropriate player; the contract's status would be updated to "complete"; the contract would be deleted from the contract list; and the contract documents would be deleted from the inventories of both contracting players. The same results would follow if any other negative condition were met, such as (since this particular contract was specified as a bilateral contract) if either player destroyed his contract document. Had this been specified as a unilateral contract, destroying a contract document would cancel the contract, which would activate the "contract destroyed" condition causing it to be removed from the contract list, but no penalty would be imposed.

 

6. AUTOMATIC RESULT APPLICATION

 

When a contract's status changes to "activated" or "failed," either the payoff or (possibly) penalty -- as agreed to by both players -- is applied immediately by the game system.

 

When a contract's status is checked and found to be "activated," the results of successfully fulfilling the terms of the contract will be carried out by crediting the agreed-upon payoff to the contracted player. In the case of a financial payoff, the money is taken from the contract's payoff account and credited to the contracted player's bank account. In the case of a payoff in goods, these are moved from the payoff account to the contracted player's inventory or bank vault. If there is insufficient room in the contracted player's inventory or bank vault (depending on which is appropriate for the type of contract activated), or insufficient goods or money available to the contracting player, then the contract's status is set to "failed," and it will proceed through the results of a broken contract (as described in the next paragraph).

 

When a contract's status is found to be "failed," the identity of the player who caused the failure is checked. Any goods or money in the payoff and provision accounts are returned to their original owners (if possible), then any penalty agreed to in the contract is applied. This could take the form of money or goods placed in the penalty account being credited to the contracting player, or if a bounty was agreed to the contract would revert to an open Assassination contract and placed back into the list of active Bounty Hunter contracts.

 

CONCLUSION

 

I don�t think the system described here is perfect. I wish there didn�t need to be specific contract types; a more general contract system would capture more kinds of economic activity. I�m not 100% sure that a game can detect all possible contract conditions � I think it can be done, but I don�t know for sure. And I do realize that implementing this system would require a lot of time and effort � the detection of contract conditions alone would require that every class of object that can be the target of a contract be made "contract-aware," for example.

 

But having admitted these things, I�m still optimistic that the new game feature I�ve described is both doable and worth doing. I think the technology will support it, and I believe that any MMOG would be made a lot more fun by players having more ways to interact economically with each other. This is especially true for Star Wars Galaxies if (as I believe) the Open Secure Contract really is the foundational technology for "player missions."

 

So, based on that optimism, I�m posting this document for you to consider. If you�ve made it this far, thanks again for your patience! And I look forward to any constructive comments you�re willing to offer.

 

TERMINOLOGY DEFINITIONS

 

Activation: the event of a contract's required conditions being met (may happen more than once in a recurring contract)

Bilateral: a contract form in which both players must agree to cancel a contract to avoid either being assessed with a penalty

Bounty Flag: an in-game variable associated with a player that is set to "true" if that player may be the target of a "bounty hunter" contract

Contract: an agreement between two players to trade goods, money, or services

Contract Document: an in-game artifact that lists the terms of a contract, a copy of which is held as an inventory item by both parties to the contract

Contracted Player: the player who initiates a contract offer

Contracting Player: the player who receives a contract offer

Credits: a generic term for any form of usable money in an online game

Default: the event of a specific player who is party to a contract causing the conditions of that contract to be impossible to meet

Draft Secure Contract: a Secure Contract that has been pre-generated by a player but has not been agreed to by another player

Griefer: someone who deliberately takes actions in an online game to spoil the enjoyment of the game for other players

MMOG: Massively Multiplayer Online Game

MMORPG: Massively Multiplayer Online Role-Playing Game

Negotiation: the interactive process by which two players take turns establishing the terms of a potential contract

NPC: Non-Player Character, or an apparently sentient creature controlled by the game computer

Open Secure Contract: a Secure Contract created by a contracting player that is offered publicly to any one player for up-or-down acceptance

Payoff Account: a container for goods or money to be transferred to the contracted player upon activation of a contract

PC: Player Character, or the in-game avatar controlled by a real person

Penalty Account: a container for money to be transferred to the player who does not default on a contract, or to a bounty hunter on successfully terminating a player who has defaulted on a contract

Personal Secure Contract: a Secure Contract created by a contracting player that is offered privately to one nearby player for negotiation

Provision Account: a container for goods or money to be transferred to the contracting player upon activation of a contract

PvE: Player versus Environment, or competitive gameplay directed against computer-controlled NPCs, creatures and objects

PvP: Player versus Player, or competitive gameplay directed against other players -- this is considered voluntary competitive gameplay, unlike griefing (q.v.)

Secure Contract: a game-enforced agreement between two players to trade goods, money, or services one or more times immediately or in the future

Secure Contract Window: a user interface for making a game-enforced agreement between two players to trade goods, money, or services one or more times immediately or in the future

Secure Trade: a game-enforced agreement between two players to trade goods and/or money once immediately

Secure Trade Window: a user interface for making a game-enforced agreement between two players to trade goods and/or money once immediately

SWG: Star Wars Galaxies, the online game set in the Star Wars universe from Sony Online Entertainment and LucasArts Entertainment Corp.

TEF: Temporary Enemy Flag, an in-game variable associated with a player that is temporarily set to "true" to indicate that a player is exposed to PvP play

Unilateral: a contract form in which either player may cancel the contract without penalty

 

 

2004/01/27

 

Great feedback, Azton-Cobalt -- this is exactly the kind of thoughtful response I was hoping to see. I'd been banging this stuff around in my head for a couple of weeks, but there's just so far one person can go -- it was time to open this concept up to other perspectives.

 

First -- and most important -- is to respond to the "degree of difficulty" question. This actually comes in two forms: one related to scope, and one based on technical considerations.

 

In terms of scope, I recognize that what I've proposed isn't an overnight coding job. I think I've managed to keep the design relatively simple (given real-world considerations such as preventing griefing and exploitation, not to mention a natural desire to add lots of "wouldn't it be cool" bells and whistles), but there's no question that a player contract system that works well will need time to get it right. I hope I didn't come across as naive about that. I think we're looking at a system that is approximately of "vehicles" complexity -- somewhere between adding a new structure type and adding the Space Expansion. Actually, I suspect that the majority of the time necessary to implement a contract system as I've proposed it would be spent not in coding, but in testing -- making sure it works and is fun, but isn't buggy or exploitable or griefable.

 

Second is the question of technical difficulty, particularly concerning what I called the single most important technical issue: reliable detection by the game itself of contract fulfillment conditions. Here I think I can provide some cause for optimism by pointing out that, if you think about it, SWG already includes a simple form of this feature in NPC missions.

 

A number of my design features were taken directly from how NPC missions currently work; which is to say, I'm piggybacking on existing functionality. When you take a mission, the game has to:

 

 

Again, all this is existing functionality within SWG. I'm inclined to think that my more general contract system has a good chance of being possible technically because it resuses this existing NPC mission technology -- I don't think I've proposed anything that isn't already being done (albeit in a simpler form).

 

The only significant new considerations I see are:

 

 

These aren't trivial issues, but at the same time I can't see any technical reason that prevents them from being possible to implement. The only really tricky one is the scaling question -- how well will the game run if it has to keep track of possibly 10-100 times more contract information? Without knowing more about how SWG is actually implemented (C with some C++ core code? strong C++ objects everywhere? procedural subroutine communication, or strongly object-oriented message passing?) I can't answer this one, but my gut tells me that an adequately efficient "contract engine" will make this possible.

 

Now, to specific points you raised:

 

I could imagine 2 players agreeing to trade thousands of credits for units of a specified resource; only to have it shift minutes after the contract was agreed upon. The system would have to be smart enough to contact both parties else 1 player could spend hours searching and another waiting for something that just will not happen.

 

Agreed. There are two things for me to say here: first, each contract type should have a broad array of game-detectable options, as this will be necessary to insure that players can tailor contracts to acceptability. For example, a Destroy contract to destroy a creature lair might need to be able to detect:

 

 

When a Destroy contract type is selected from the Secure Contract Window, these potential situations could be reflected in the terms of the contract, possibly by radio buttons if well-defined, or by a dynamically-built drop-down menu if dependent on other game conditions. The parties to the contract could then choose which condition they wanted to have treated as the "success" condition, and which conditions constituted "failure" conditions; any conditions not explicitly identified could be treated as what we might call "acceptable" conditions: the contract ends, but no penalty is assessed.

 

Other types of contracts would need to be similarly studied to identify the right set of conditions to monitor, and to determine whether the game can efficiently monitor them (both individually and in the aggregate).

 

some players might actually enjoy stiffing others on contracts and running from the BHs, rarely logging on, or even re-rolling characters as a form of griefing. There would have to be some sort of reputation count in place where if a player defaulted on a contract, did not pay his way out, and was not brought to justice, that others would be informed of this before they signed new contracts with the player.

 

As they say in the Guinness commercial: "Brilliant!" J Your point about "kill me now!" griefers is a very good one, and as for your proposed solution... well, I'll give it the highest compliment I know: "I wish I'd thought of that."

 

There's been some talk whenever the subject of "deals with other players" comes up of wanting a way to know whether the other potential party to the deal is a bad risk. The usual model for how to do this is the "eBay rating" model, in which buyers are given a rating by sellers and vice-versa. The problem with something like this in SWG (or MMOGs in general) is that some gamers would abuse the system. Because they don't stick around, they feel free to lie; but those lies would typically be retained by a rating system.

 

So the eBay model wouldn't be a good idea for keeping track of players who can't be trusted to honor contracts... but who says we have to use the eBay model? You're absolutely right -- all we need is a simple "number of contracts broken" counter, or possibly a percentage ratio of "contracts broken" to "contracts signed" if we wanted to get fancy. This number would be absolutely objective since it would be maintained exclusively by the game system itself.

 

The only negative I can imagine is that tagging every user of contracts with this information would cause some players to not use contracts, due to a concern that they would inadvertently break some contracts and be unfairly branded as a "contract-breaker." This is a perception issue and thus hard to counter. One possibility would be to allow "aging" of contract resolution data -- in other words, the contract counter only retains the most recent 1-6 months of contract resolution results, so that if you have a run of bad luck your "broken contract" number or percentage will eventually recover. I'm not too enthusiastic about that option, but it would be possible if enough players found it acceptable.

 

Another option would be to allow players to explicitly specify which contract conditions should be treated as "no-fault" failure conditions. That is, the Secure Contract Window would list every possible condition relevant to a particular contract type, then the parties to that contract would be able to negotiate which one of three categories that condition should fall into for contract resolution:

 

 

If all success conditions become true, the contract is activated. If any failure condition becomes true, the contract is terminated and any penalty provisions are applied. And if any acceptable condition becomes true, the contract is terminated but no penalty is assessed.

 

As long as the list of possible conditions relevant to a contract type is sufficiently extensive and detailed to allow players to feel that they can craft contracts to be fair to both parties if something goes wrong, then the value of having a "broken contracts" counter (for identifying the bad risks) should outweigh the perceived cost.

 

A player would a single unit of a wanted resource into the interface, and type in a reward per unit number. The player could then dump a few thousand credits in the machine to activate the contract. Others could come along, read the contract, decide to accept, and would be paid for each unit of the correct resource they dropped onto the interface.

 

I have to admit that I have some reservations about this one. Specifically, I'm not sure it's wise to allow many-to-one contracts.

 

Imagine writing a valuable contract ("I'll give you 10 cr/unit for any Class 3 radioactive") and then plunking it down onto a contract terminal in Coronet. There are known limits to what one player can mine. This allows a contracting player to write a contract he can afford to fill (i.e., he's got enough money to pay for whatever one person can bring). But if you open this up to a theoretically limitless number of players, there's no telling how much money the contracting player might be on the hook for! If he posted such a contract and logged out, he could return to find that he now owned millions units of junk class 3 radioactives, but was utterly broke. Not good.

Unless the contract was written so that the contracting player couldn't be considered to have "broken" the contract if he didn't offer any money to someone who brought in some amount of the desired resource, the contracting player could wind up with a bad reputation for having left an unfulfillable contract out there. At a minimum, there'd be a lot of unhappy players when this "Really Open" contract got pulled after just a few minutes (once the contracting player had all the Class 3 radioactive units he wanted).

 

Better, I think, to limit contracts to two parties. The second party might only be defined once the open contract is accepted, but I think "predictability of response" is a sufficiently powerful justification for holding the number of parties to a contract to two.

 

Note: One of the possible enhancements to contracts I'm still mulling over is related to another of the economic advancements I identified in my "Advanced Online Economic Systems" message back in the late Discussion forum; namely, the corporation.

 

My idea for implementing player corporations was to allow a generalized hierarchical organization. That is, you'd be able to create a structure that links players in superior/inferior relationships, possibly even allow the creator of such structures to name the various levels and groupings. This would allow the creation not only of corporations, but of crafting guilds, entertainer unions, paramilitary units, and so on.

 

If this is done, then it occured to me that it would be useful to allow the identification of the player at the top of such an organization to create and agree to contracts on behalf of that organization. This would give organizations more effectiveness as it would dramatically increase the "purchasing power" of the head of that organization as its representative. (It also models the real-world treatment of corporations as "corporate" entities nearly on a par with actual human beings before the law in some specific areas, which could eventually have some interesting gameplay potential.)

 

But, as I say, I'm still thinking about this one.

 

A more complex system might allow the setup of 2 connected contracts to facilitate the delivery, obtain, and transport exchange types you mentioned.

 

Wow. This is another idea I really like.

 

"Chaining" contracts could have some wildly interesting results. Heck, an entire business specialization has sprung up in the real world to handle "supply chain management." Playing SWG shouldn't be like having a real job (that's what playing The Sims is for ), but creating systems that allow more economic interactions (both low-level and high-level) is exactly what I'm hoping to accomplish with this "player contracts" proposal.

 

Even more interesting, how about contracts that don't merely chain to one other contract, but that actually can monitor the results of multiple other contracts as conditions, and kick off multiple other contracts when activated or terminated? If contracts could be bought and sold, a group of such contracts that filter upward into a single master contract could be considered a business in and of themselves -- you could actually sell an entire business by selling the master contract!

 

(OK, I'm getting a little blue-sky here. But this kind of possibility does exist once you get the basic elements of a contract system working and start considering enhancements. Which is nice. J)

 

 

2004/02/03

 

R2DADROID wrote:

Let me see if I can explain what I was trying to get at more clearly to see if we are on the same page.

 

We're definitely on the same page.

 

My system is actually a little different, but you've got the idea. Still, just for clarity's sake let me go through your example as it would work in the contract system as currently designed.

 

The main thing to note is that I think of a contract as having three "boxes" into which anything (usually goods or money) can go:

 

 

Assuming there was a way to allow purchased items to be transferred from a waiting Bazaar terminal to a contract Provision Account (something I didn't think of but that is an excellent idea), the contract would be loaded up in something like the following way:

 

The Payoff Account would contain the 1000 credits you offer for delivering the hat. The moment the contract is accepted this money would be transferred from your bank account to the contract's Payoff Account. (If you don't have enough cash in your bank account at that instant to pay off the deal, it never happens. This helps increase trust in the system.)

 

The Provision Account would contain the hat you purchased. Note that the player who takes the delivery contract never actually has the hat itself as an inventory item. It's considered to be "stored" in the contract's "inventory" to which players don't have any access -- the system itself automatically handles all transfers if it decides that a contract has been successfully activated (or item/money restorals if it decides that a contract has been broken).

 

The Penalty Account would hold whatever sum you and the contracting player decided was fair as a penalty for failure to meet the other terms of the contract. To insure you against having your time wasted, you could set the Penalty amount at 1,000 credits. To take the deal, a contracting player would have to put up 500 credits (and so would you). This money would be transferred from each player's bank account the instant both parties agree to the deal -- this insures that the penalty can and will definitely be paid if anything happens that breaks the contract. Again, the point is to help players trust that the system will work in their favor as long as they intend to honor the contracts they sign.

 

So when a player honors this particular contract, several things happen:

 

 

But what about those without honor? Well, if a contracting player decides that he just wants to annoy you, several things happen the moment he breaks the contract:

 

 

In other words, if a would-be griefer breaks your contract everything gets reset to exactly where it was before you wrote the contract -- the hat is still available to you and you're not out a single credit (since the 1500 you paid into the Payoff and Penalty accounts is restored to your bank account). There are only two differences:

 

  1. You're out however many minutes it took for all this to happen.
  2. The griefer lost 500 credits and you've got them.

 

The obvious potential problem here is that a rich griefer could run around taking contracts he has no intention of fulfilling. This is easily minimized: don't let anyone become a contracting player for more than N contracts (where N is some low number like 5 or 2). Player should probably be allowed to offer as many contracts as they like, since the fact that they have to put up goods or money in the Payoff account up front will tend to limit how many contracts they can offer.

 

From the griefer's point of view, the only practical result of griefing someone would be that they themselves lose money nearly every time they break a contract -- the griefed party wouldn't be out anything but a little time (during which they were somewhere else doing other other things). I suspect this setup would tend to limit griefage pretty effectively.

 

My concern was really just about how to prevent item loss.

So I thought making it so no item actually gets traded would keep that from happening.

I don't see how this system could be griefed.

 

Yep -- I think we're seeing basically the same picture here.